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REMARKS 

Specification 

Line 27 on page 12 has been amended to replace "ore" with "or". 
Claims 

The claims have been amended throughout to replace the term "network entity" with 
"resource provider" in order to make the language of the claims more consistent with 
those in the specification. 

Claim 1 has been amended to be substantially similar to the combination of features 
in former Claims 1, 3, 5 and 6. Claim 1 has been further amended to specify that 
the network server is a "Generic Local Lookup Service* (GLLS) and the global 
network server is a "Generic Domain Lookup Service 11 . 

Claim 2 has been amended to further specify the information which may be included 
in the resource request. 

Claims 5, 7,8, 10, 12, 13, 19 to 21, 25 to 28, 31 and 32 have been amended so that 
the terminology in the claims are consistent with that in Claim 1. Claim 29 has 
additionally been amended to specify that the content manager is a "Content 
Distribution Point Manager" as recited in the specification. 

Claim 30 has been amended to include all the features in amended Claim 1. 

New claims 34 to 36 have been added. Claim 34 is directed towards the list of 
service providers being in order of the compatibility with the resource request. 
Claims 35 and 36 are directed towards the presence of a Content Distribution Point 
Manager present in the GLLS and GDLS respectively. No fee is due in view of the 
cancelled claims. 

Claims 3, 4, 6 ( 9, 11 and 14 to 18 have been cancelled. 
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Applicants submit that Jindal does not disclose the feature of a *a Generic Local 
Lookup Service (GLLS) at a network edge and a Generic Domain Lookup System 
(GDLS) at a central location in a network" or the features of "receiving a resource 
request at the GLLS from a client, the resource request identifying the requested 
resource; the GLLS forwarding the resource request to the GDLS; the GDLS 
searching a database for a resource record associated with the requested resource 
the resource record including a series of executable instructions; the GDLS 
analysing a set of resource providers and determining the resource providers 
compatible with the resource request; the GDLS transmitting a response containing 
a list of resource providers to the GLLS, the list including server selection criteria 
associated with the resource providers; [and] the GLLS selecting the best resource 
provider in the list according to the server selection criteria" as claimed in Claim 1. 

Rather, the invention in Jindal provides a single DNS server to load balance the 
distribution of requests according to criteria such as the server's "response time for 
a client request, its operational status..., the number of client requests pending with 
the instance, its throughput.., etc," (Column 6 lines 45 to 50). Alternatively the load 
balancing may be provided by a group of segregated servers which a may be 
considered a single entity for the purposes of a a global n load balancing policy 
specifying the manner in which all client requests for the application are to be 
distributed among all participating servers" (Column 1 1 lines 27 to 31). 

The configuration of the network in Jindal has a number of disadvantages. Firstly, a 
single server controlling load balancing will either be located at the edge of a 
network or alternatively in a central position. A server at the edge of a network will 
only see local service providers and therefore only local service providers will be 
considered for providing a resource. However, these local service providers may 
not be the most suitable for providing a service, for example, a client may wish to 
have a high speed connection and a provider able to provide a higher speed 
connection than any provider listed with the server will not be taken into account 
when selecting the service provider. 

A centralized server on the other hand will need to have connections to many 
service providers in order to co-ordinate the distribution of service provision within 
the network. This will necessarily use high amounts of bandwidth in the network 
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and large amounts of processing power at the server as large amounts of 
information regarding the service providers will need to be co-ordinated. 

The present invention by having two servers, the GLLS and GDLS, the GLLS can 
maintain data at a local level yet the GDLS can be utilized to consult data present at 
multiple GLLSs in order to provide a truer picture of the best possible service 
providers within the network. The GLLS can then select the preferred service 
provider from a greater pool. In this way the amount of data needing to be sent to 
co-ordinate load balancing and the processing power at the servers is minimized 
whilst maximizing the number of service providers being considered in response to a 
resource request. 

Applicants therefore submit that Claims 1 and 30 are not anticipated by or obvious in 
view of Jindal. 

Claims 25 and 26 are directed towards "a response to a resource request message 
from a GDLS to a GLLS" and a "resource request from a GLLS to a GDLS* 
respectively. For the reasons given above Applicants submit that Jindal does not 
disclose the sending of messages between two servers responsible for different 
parts of a load-balancing operation. Applicants therefore submit that neither Claim 
25 nor Claim 26 are anticipated by or obvious in view of Jindal. 

Claim 27 recites the features of a GLLS and a GDLS configured as described above 
within a scalable architecture. Applicants therefore submit that Claim 27 is not 
anticipated by or obvious In view of Jindal. 

Applicants submit that Claims 2, 5, 7, 8, 10, 12, 13, 19 to 24. 28, 29 and 31 to 36 are 
not anticipated by or obvious in view of Jindal at least by virtue of their 
dependencies. 
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In view of the above, further and favorable reconsideration are urged. 



July 27, 2005 



Respectfully submitted, 




Registration No. 26,935 U 
Barnes & Thornburg LLP^* 
P.O. Box 2786 
Chicago, Illinois 60690-2786 
(312) 214-4800 
(312) 759-5646 (fax) 
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